アクセス元制限を行う Self-Managed 版 GitLab を AWS CodePipeline のソースプロバイダーとして使えるか検証した

いわさです。

先日、CodePipeline のソースプロバイダーに Self-Managed 版 GitLab を使う方法を紹介しました。

こちらの記事ですが、アクセス経路としては次のような形になってまして、GitLab 側は CodePipeline マネージドなネットワークからインターネット経路でのアクセスとなります。

上記パターンですが、フルオープンな GitLab 環境の場合はこれで良いのですが、私がこれまで Self-Managed 版 GitLab をお仕事で使う場合は全て IP アドレスでのアクセス制限がされていました。

そういった環境では CodePipeline が使う IP アドレスを知っておく必要がありますが、公式ドキュメントを確認した限りでは非 VPC 構成を選択した場合のアクセス元 IP アドレスについて特定出来る記述が見当たりませんでした。
当然ながらこの状態で GitLab へのアクセス元を制限しようとすると、CodePipeline からパイプラインを実行した際にパイプラインのソースステージでソースコードの取得が出来ません。

VPC 構成機能が使える

解決策として、今回の Self-Managed GitLab アクセス機能では VPC 構成を選択することが出来ます。
こちらを使うと、指定した VPC に CodeStar 接続用の ENI が作成されそこがアクセス元になります。
そのため次のように NAT Gateway を使ってパブリック IP アドレスの固定化を行ったり、VPC ピアリングや VPN を使って AWS やオンプレミスなどでのインターネットアクセスが不可能な環境へのプライベートアクセスを構成することも出来ます。

本日はこちらの機能を使い、NAT Gateway 経由で CodePipeline からセキュリティグループで制限された GitLab on EC2 へアクセス出来るか試してみましたので紹介します。

ホストと接続の作成時に VPC を使用する

事前にアクセスに使用する VPC は準備済みとします。
前回と異なる点としては、デベロッパー用ツールでホストを作成する際に「VPC を使用」オプションを選択します。

「VPC を使用」を選択した場合は、対象の VPC、サブネット、セキュリティグループを設定します。
ここで指定したネットワーク設定で ENI が作成されます。

作成するとホストのセットアップステータスが「VPC 設定を初期化しています」となりました。前回とちょっと違いますね。
またホストの基本情報として VPC をはじめとするネットワーク設定情報も表示されるようになりました。

この時点でネットワークインターフェイスコンソールを確認してみると、ありました。
ホスト用の ENI が作成されていますね。先程指定したサブネット内に、指定したセキュリティグループが割り当てられていますね。

少し待つと、ホストのセットアップステータスが前回と同じように「保留中」となりました。
あとは前回と同様にホストのセットアップで個人用アクセストークンを設定しましょう。

なお、この個人用アクセストークンを設定する際に GitLab への通信が発生するようなので、この時点で CodePipeline（接続・ホスト） で使う ENI から Self-Managed GitLab へのネットワーク経路を確保しておく必要があります。
ここでは次のように GitLab 側のセキュリティグループインバウンドルールへホストが属する VPC の NAT Gateway パブリック IP アドレスを設定しました。

そうすると無事ホストのセットアップステータスが「利用可能」になりましたね。
アクセス出来ない状態だとホストセットアップ中に通信エラーとなりますのでご注意ください。

続いて接続も作成しましょう。
先程作成したホストを選択すると自動で選択済みの VPC 設定が選択されます。変更は出来ません。

あとは接続についても「保留中の接続を更新」からアクセスの認可を行う必要があるのですが、ここはユーザー操作が必要なので、ホストではなくブラウザから GitLab へのアクセスが必要になりますので許可するアクセス元を制限している場合はご注意ください。

接続とホストが利用可能になったら、CodePipeline のソースステージで選択してみましょう。
パイプラインを実行してみると無事取得に成功しました。

さいごに

本日はアクセス制限を行う Self-Managed 版 GitLab に対して CodePipeline でアクセスしてみました。

これは Self-Managed 版 GitLab の主要なユースケースとして使えそうです。
今回は NAT Gateway に対して試してみましたが、名前解決や証明書の課題がクリア出来れば Direct Connect や VPN を使ってオンプレミスでホストする GitLab をソースプロバイダーとして AWS 上でビルドやデプロイを実行することも出来そうですね。